Forecasting SDN fabric saturation and machine learning-based flow admission control

ABSTRACT

In one embodiment, a device of a software defined wide area network (SD-WAN) predicts characteristics of a new traffic flow to be admitted to the SD-WAN, based on a set of initial packets of the flow. The device predicts an impact of admitting the flow to the SD-WAN, based in part on extrinsic or exogenous data regarding the SD-WAN. The device admits the flow to the SD-WAN, based on the predicted impact. The supervisory device uses reinforcement learning to adjust one or more call admission control (CAC) parameters of the SD-WAN, based on captured telemetry data regarding the admitted flow.

RELATED APPLICATION

This application is continuation-in-part of U.S. patent application Ser.No. 16/274,567, filed Feb. 13, 2019, entitled “FORECASTING SDN FABRICSATURATION AND MACHINE LEARNING-BASED FLOW ADMISSION CONTROL,” byPatrick Wetterwald, et al., the contents of which are incorporatedherein by reference.

TECHNICAL FIELD

The present disclosure relates generally to computer networks, and, moreparticularly, to forecasting saturation in software defined networking(SDN) fabrics and using machine learning-based flow admission control inSDN fabrics.

BACKGROUND

Software defined networking (SDN) represents an evolution of computernetworks away from a decentralized architecture to one of centralized,software-based control. More specifically, in traditional computernetworks, the control plane (e.g., selection of the routing path) andthe data plane (e.g., forwarding packets along the selected path) areintertwined, with control plane decisions being made in a decentralizedmanner via signaling between the networking devices. In contrast,control plane decisions in an SDN-based network architecture are made bya centralized controller and pushed to the networking devices, asneeded.

While applicable to any number of different types of networkdeployments, SDN is particularly of relevance to cloud service providernetworks. Indeed, in a traditional client-server architecture, thenetwork need only support traffic between the client and the server.However, with cloud computing, each transaction with a client may resultin a large amount of “east-west” traffic between nodes in the cloud(e.g., to perform a query or computation in parallel, etc.), as well asthe traditional “north-south” traffic between the cloud and the client.In addition, the very nature of cloud computing environments allows forthe rapid scaling of resources with demand, such as by spinning newnodes up or down. In such situations, centralized control over thecontrol plane results in better network performance over that ofdecentralized control. However, despite the overall benefits of SDN,flow admission control and network fabric saturation remain challengingin SDN fabrics. Indeed, admitting a flow to the SDN fabric that requirestoo many resources could cause a saturation condition to occur in whichthere are not enough resources available to support all of the flows.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments herein may be better understood by referring to thefollowing description in conjunction with the accompanying drawings inwhich like reference numerals indicate identically or functionallysimilar elements, of which:

FIGS. 1A-1B illustrate an example communication network;

FIG. 2 illustrates an example network device/node;

FIGS. 3A-3B illustrate examples of software defined networking (SDN)fabric implementations;

FIG. 4 illustrates an example heatmap for an SDN fabric;

FIG. 5 illustrates an example architecture for flow admission control inan SDN fabric;

FIGS. 6A-6B illustrate example software defined wide area network(SD-WAN) deployments;

FIG. 7 illustrates an example SD-WAN node implementation; and

FIG. 8 illustrates an example simplified procedure for admitting a flowto an SD-WAN.

DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

According to one or more embodiments of the disclosure, a supervisorydevice for a software defined networking (SDN) fabric predictscharacteristics of a new traffic flow to be admitted to the fabric,based on a set of initial packets of the flow. The supervisory devicepredicts an impact of admitting the flow to the SDN fabric, using aheatmap-based saturation model for the SDN fabric. The supervisorydevice admits the flow to the SDN fabric, based on the predicted impact.The supervisory device uses reinforcement learning to adjust one or morecall admission control (CAC) parameters of the SDN fabric, based oncaptured telemetry data regarding the admitted flow.

In further embodiments, a device of a software defined wide area network(SD-WAN) predicts characteristics of a new traffic flow to be admittedto the SD-WAN, based on a set of initial packets of the flow. The devicepredicts an impact of admitting the flow to the SD-WAN, based in part onextrinsic data or exogenous information regarding the SD-WAN. The deviceadmits the flow to the SD-WAN, based on the predicted impact. Thesupervisory device uses reinforcement learning to adjust one or morecall admission control (CAC) parameters of the SD-WAN, based on capturedtelemetry data regarding the admitted flow.

DESCRIPTION

A computer network is a geographically distributed collection of nodesinterconnected by communication links and segments for transporting databetween end nodes, such as personal computers and workstations, or otherdevices, such as sensors, etc. Many types of networks are available,with the types ranging from local area networks (LANs) to wide areanetworks (WANs). LANs typically connect the nodes over dedicated privatecommunications links located in the same general physical location, suchas a building or campus. WANs, on the other hand, typically connectgeographically dispersed nodes over long-distance communications links,such as common carrier telephone lines, optical lightpaths, synchronousoptical networks (SONET), or synchronous digital hierarchy (SDH) links,or Powerline Communications (PLC) such as IEEE 61334, IEEE P1901.2, andothers. The Internet is an example of a WAN that connects disparatenetworks throughout the world, providing global communication betweennodes on various networks. The nodes typically communicate over thenetwork by exchanging discrete frames or packets of data according topredefined protocols, such as the Transmission Control Protocol/InternetProtocol (TCP/IP). In this context, a protocol consists of a set ofrules defining how the nodes interact with each other. Computer networksmay further be interconnected by an intermediate network node, such as arouter, to extend the effective “size” of each network.

Smart object networks, such as sensor networks, in particular, are aspecific type of network having spatially distributed autonomous devicessuch as sensors, actuators, etc., that cooperatively monitor physical orenvironmental conditions at different locations, such as, e.g.,energy/power consumption, resource consumption (e.g., water/gas/etc. foradvanced metering infrastructure or “AMI” applications) temperature,pressure, vibration, sound, radiation, motion, pollutants, etc. Othertypes of smart objects include actuators, e.g., responsible for turningon/off an engine or perform any other actions. Sensor networks, a typeof smart object network, are typically shared-media networks, such aswireless networks. That is, in addition to one or more sensors, eachsensor device (node) in a sensor network may generally be equipped witha radio transceiver or other communication port, a microcontroller, andan energy source, such as a battery. Often, smart object networks areconsidered field area networks (FANs), neighborhood area networks(NANs), personal area networks (PANs), etc. Generally, size and costconstraints on smart object nodes (e.g., sensors) result incorresponding constraints on resources such as energy, memory,computational speed and bandwidth.

FIG. 1A is a schematic block diagram of an example computer network 100illustratively comprising nodes/devices, such as a plurality ofrouters/devices interconnected by links or networks, as shown. Forexample, customer edge (CE) routers 110 may be interconnected withprovider edge (PE) routers 120 (e.g., PE-1, PE-2, and PE-3) in order tocommunicate across a core network, such as an illustrative networkbackbone 130. For example, routers 110, 120 may be interconnected by thepublic Internet, a multiprotocol label switching (MPLS) virtual privatenetwork (VPN), or the like. Data packets 140 (e.g., traffic/messages)may be exchanged among the nodes/devices of the computer network 100over links using predefined network communication protocols such as theTransmission Control Protocol/Internet Protocol (TCP/IP), User DatagramProtocol (UDP), Asynchronous Transfer Mode (ATM) protocol, Frame Relayprotocol, or any other suitable protocol. Those skilled in the art willunderstand that any number of nodes, devices, links, etc. may be used inthe computer network, and that the view shown herein is for simplicity.

In some implementations, a router or a set of routers may be connectedto a private network (e.g., dedicated leased lines, an optical network,etc.) or a virtual private network (VPN), such as an MPLS VPN, thanks toa carrier network, via one or more links exhibiting very differentnetwork and service level agreement characteristics. For the sake ofillustration, a given customer site may fall under any of the followingcategories:

1.) Site Type A: a site connected to the network (e.g., via a private orVPN link) using a single CE router and a single link, with potentially abackup link (e.g., a 3G/4G/LTE backup connection). For example, aparticular CE router 110 shown in network 100 may support a givencustomer site, potentially also with a backup link, such as a wirelessconnection.

2.) Site Type B: a site connected to the network using two MPLS VPNlinks (e.g., from different service providers), with potentially abackup link (e.g., a 3G/4G/LTE connection). A site of type B may itselfbe of different types:

2a.) Site Type B1: a site connected to the network using two MPLS VPNlinks (e.g., from different service providers), with potentially abackup link (e.g., a 3G/4G/LTE connection).

2b.) Site Type B2: a site connected to the network using one MPLS VPNlink and one link connected to the public Internet, with potentially abackup link (e.g., a 3G/4G/LTE connection). For example, a particularcustomer site may be connected to network 100 via PE-3 and via aseparate Internet connection, potentially also with a wireless backuplink.

2c.) Site Type B3: a site connected to the network using two linksconnected to the public Internet, with potentially a backup link (e.g.,a 3G/4G/LTE connection).

Notably, MPLS VPN links are usually tied to a committed service levelagreement, whereas Internet links may either have no service levelagreement at all or a loose service level agreement (e.g., a “GoldPackage” Internet service connection that guarantees a certain level ofperformance to a customer site).

3.) Site Type C: a site of type B (e.g., types B1, B2 or B3) but withmore than one CE router (e.g., a first CE router connected to one linkwhile a second CE router is connected to the other link), andpotentially a backup link (e.g., a wireless 3G/4G/LTE backup link). Forexample, a particular customer site may include a first CE router 110connected to PE-2 and a second CE router 110 connected to PE-3.

FIG. 1B illustrates an example of network 100 in greater detail,according to various embodiments. As shown, network backbone 130 mayprovide connectivity between devices located in different geographicalareas and/or different types of local networks. For example, network 100may comprise local networks 160, 162 that include devices/nodes 10-16and devices/nodes 18-20, respectively, as well as a data center/cloudenvironment 150 that includes servers 152-154. Notably, local networks160-162 and data center/cloud environment 150 may be located indifferent geographic locations.

Servers 152-154 may include, in various embodiments, a networkmanagement server (NMS), a dynamic host configuration protocol (DHCP)server, a constrained application protocol (CoAP) server, an outagemanagement system (OMS), an application policy infrastructure controller(APIC), an application server, etc. As would be appreciated, network 100may include any number of local networks, data centers, cloudenvironments, devices/nodes, servers, etc.

The techniques herein may also be applied to other network topologiesand configurations. For example, the techniques herein may be applied topeering points with high-speed links, data centers, etc. Further, invarious embodiments, network 100 may include one or more mesh networks,such as an Internet of Things network. Loosely, the term “Internet ofThings” or “IoT” refers to uniquely identifiable objects/things andtheir virtual representations in a network-based architecture. Inparticular, the next frontier in the evolution of the Internet is theability to connect more than just computers and communications devices,but rather the ability to connect “objects” in general, such as lights,appliances, vehicles, heating, ventilating, and air-conditioning (HVAC),windows and window shades and blinds, doors, locks, etc. The “Internetof Things” thus generally refers to the interconnection of objects(e.g., smart objects), such as sensors and actuators, over a computernetwork (e.g., via IP), which may be the public Internet or a privatenetwork.

Notably, shared-media mesh networks, such as wireless networks, etc.,are often on what is referred to as Low-Power and Lossy Networks (LLNs),which are a class of network in which both the routers and theirinterconnect are constrained. In particular, LLN routers typicallyoperate with highly constrained resources, e.g., processing power,memory, and/or energy (battery), and their interconnections arecharacterized by, illustratively, high loss rates, low data rates,and/or instability. LLNs are comprised of anything from a few dozen tothousands or even millions of LLN routers, and support point-to-pointtraffic (e.g., between devices inside the LLN), point-to-multipointtraffic (e.g., from a central control point such at the root node to asubset of devices inside the LLN), and multipoint-to-point traffic(e.g., from devices inside the LLN towards a central control point).Often, an IoT network is implemented with an LLN-like architecture. Forexample, as shown, local network 160 may be an LLN in which CE-2operates as a root node for nodes/devices 10-16 in the local mesh, insome embodiments.

FIG. 2 is a schematic block diagram of an example node/device 200 thatmay be used with one or more embodiments described herein, e.g., as anyof the computing devices shown in FIGS. 1A-1B, particularly the PErouters 120, CE routers 110, nodes/device 10-20, servers 152-154 (e.g.,a network controller located in a data center, etc.), any othercomputing device that supports the operations of network 100 (e.g.,switches, etc.), or any of the other devices referenced below. Thedevice 200 may also be any other suitable type of device depending uponthe type of network architecture in place, such as IoT nodes, etc.Device 200 comprises one or more network interfaces 210, one or moreprocessors 220, and a memory 240 interconnected by a system bus 250, andis powered by a power supply 260.

The network interfaces 210 include the mechanical, electrical, andsignaling circuitry for communicating data over physical links coupledto the network 100. The network interfaces may be configured to transmitand/or receive data using a variety of different communicationprotocols. Notably, a physical network interface 210 may also be used toimplement one or more virtual network interfaces, such as for virtualprivate network (VPN) access, known to those skilled in the art.

The memory 240 comprises a plurality of storage locations that areaddressable by the processor(s) 220 and the network interfaces 210 forstoring software programs and data structures associated with theembodiments described herein. The processor 220 may comprise necessaryelements or logic adapted to execute the software programs andmanipulate the data structures 245. An operating system 242 (e.g., theInternetworking Operating System, or IOS®, of Cisco Systems, Inc.,another operating system, etc.), portions of which are typicallyresident in memory 240 and executed by the processor(s), functionallyorganizes the node by, inter alia, invoking network operations insupport of software processors and/or services executing on the device.These software processors and/or services may comprise a fabricsaturation analysis process 248.

It will be apparent to those skilled in the art that other processor andmemory types, including various computer-readable media, may be used tostore and execute program instructions pertaining to the techniquesdescribed herein. Also, while the description illustrates variousprocesses, it is expressly contemplated that various processes may beembodied as modules configured to operate in accordance with thetechniques herein (e.g., according to the functionality of a similarprocess). Further, while processes may be shown and/or describedseparately, those skilled in the art will appreciate that processes maybe routines or modules within other processes.

In general, fabric saturation analysis process 248 may execute one ormore machine learning-based models to predict traffic congestion in anetwork and, based on the predictions, initiate corrective measures whenthere is likely to be congestion. Fabric saturation analysis process 248may employ any number of machine learning techniques, to classify thegathered telemetry data. In general, machine learning is concerned withthe design and the development of techniques that receive empirical dataas input (e.g., telemetry data regarding traffic in the network) andrecognize complex patterns in the input data. For example, some machinelearning techniques use an underlying model M, whose parameters areoptimized for minimizing the cost function associated to M, given theinput data. For instance, in the context of classification, the model Mmay be a straight line that separates the data into two classes (e.g.,labels) such that M=a*x+b*y+c and the cost function is a function of thenumber of misclassified points. The learning process then operates byadjusting the parameters a,b,c such that the number of misclassifiedpoints is minimal. After this optimization/learning phase, fabricsaturation analysis process 248 can use the model M to classify new datapoints, such as information regarding new traffic flows in the network.Often, M is a statistical model, and the cost function is inverselyproportional to the likelihood of M, given the input data.

In various embodiments, fabric saturation analysis process 248 mayemploy one or more supervised, unsupervised, or semi-supervised machinelearning models. Generally, supervised learning entails the use of atraining set of data, as noted above, that is used to train the model toapply labels to the input data. For example, the training data mayinclude sample telemetry data that is labeled as “normal,” or“saturation-related.” On the other end of the spectrum are unsupervisedtechniques that do not require a training set of labels. Notably, whilea supervised learning model may look for previously seen patterns thathave been labeled as such, an unsupervised model may instead look towhether there are changes in the behavior of the network traffic overtime. Semi-supervised learning models take a middle ground approach thatuses a greatly reduced set of labeled training data.

Example machine learning techniques that fabric saturation analysisprocess 248 can employ may include, but are not limited to, nearestneighbor (NN) techniques (e.g., k-NN models, replicator NN models,etc.), statistical techniques (e.g., Bayesian networks, etc.),clustering techniques (e.g., k-means, mean-shift, etc.), neural networks(e.g., reservoir networks, artificial neural networks, etc.), supportvector machines (SVMs), logistic or other regression, Markov models orchains, principal component analysis (PCA) (e.g., for linear models),multi-layer perceptron (MLP) ANNs (e.g., for non-linear models),replicating reservoir networks (e.g., for non-linear models, typicallyfor time series), random forest classification, or the like.

The performance of a machine learning model can be evaluated in a numberof ways based on the number of true positives, false positives, truenegatives, and/or false negatives of the model. For example, the falsepositives of the model may refer to the number of times the modelincorrectly predicted there to be saturation within a network fabric.Conversely, the false negatives of the model may refer to the number oftimes the model incorrectly predicted normal operation of the network,when saturation actually resulted. True negatives and positives mayrefer to the number of times the model correctly predicted either normalbehavior or saturation, respectively. Related to these measurements arethe concepts of recall and precision. Generally, recall refers to theratio of true positives to the sum of true positives and falsenegatives, which quantifies the sensitivity of the model. Similarly,precision refers to the ratio of true positives the sum of true andfalse positives.

As noted above, software defined networking (SDN) represents anevolution of computer networks that centralizes control plane decisionswith a supervisory device. For example, in Application CentricInfrastructure (ACI), an SDN-based architecture from Cisco Systems,Inc., control plane decisions may be made by a centralized APIC.However, even with centralized control, there still exists the potentialfor seasonal congestion to occur on certain links in the network fabric.

In general, an SDN-based network fabric may utilize a leaf-spinearchitecture, such as CLOS and Fat-Tree architectures. This isparticularly true in the case of data center and cloud networks that arepoised to deliver the majority of computation and storage services inthe future. In a Fat-Tree, nodes are organized in a tree structure withbranches becoming ‘fatter’ towards the top of the hierarchy. In thecontext of computer networks, this increasing ‘fatness’ typicallycorresponds to increasing bandwidth towards the top of the hierarchy.CLOS networks typically involve multiple stages (e.g., an ingress stage,a middle stage, and an egress stage), with ‘crossbar’ switches atdifferent stages that are interwoven such that multiple paths areavailable for switching, so that one traffic flow does not blockanother.

As would be appreciated, an SDN fabric that implements a leaf-spinearchitecture may operate by emulating a very large switch byinterleaving many smaller switches, resulting in much lower cost andhigher scalability. The benefits of such designs include, but are notlimited to, the availability of an equal cost multi-path (ECMP) basedswitching fabric, a simplified network, and fully utilized linkbandwidth on each network node. It also allows the networks to scale andgrow incrementally, on demand. Cisco's next generation SDN based datacenter network fabric architecture, ACI, is also based on CLOS designprinciples.

FIG. 3A illustrates a simplified example of an SDN fabric 300 that usesa leaf-spine architecture. As shown, the network switches S1-S4 andL1-L6 may be organized according to CLOS design principles. Inparticular, switches S1-S4 may form a superspine layer 302. This layeris also sometimes called the Top of Fabric (ToF) layer, such as in RIFT.At the south of fabric 300 is a leaf layer 306 that comprises switchesL1-L6 and provide connectivity to the various clients of fabric 300,such as endpoints or virtual machines (VMs), and implement Layer 2bridging and Layer 3 routing functions. Likewise, S1-S4 in superspinelayer 302 may be fully meshed with L1-L6 in leaf layer 306 viaconnections 304, which are not actual links, in the physical sense.During operation, S1-S4 may provide redundant paths and connectivityfrom a previous lower-level stage switch in the network fabric.

FIG. 3B illustrates another example SDN fabric 310 that uses aCLOS-based approach. As shown, at the top of fabric 310 are switchesS1-S4 that form a superspine layer 312 that are connected to a middlelayer 314 comprising switches M1-M6 which are, in turn, connected to aleaf layer 316 comprising switches L1-Lc. The overall function of fabric310 may be similar to that of fabric 300 in FIG. 3A, with the additionof middle layer 314 that may perform, for example, aggregationfunctions. Leaf switches and their corresponding switches in middlelayer 314 may also form pods, such as pod 318 a shown.

Today, a large, virtualized data center fabric might be comprised ofapproximately 500-1000 leaf switches and as many as approximately 8-16spine switches servicing many of its tenant's virtual networks on theshared, physical network infrastructure. Each leaf switch, in turn, maybe connected to between 32-98 physical hypervisor servers, with eachserver hosting approximately 20 virtual servers/endpoints that estimateto between 1000-2000 endpoints connected per leaf switch. In such ashared network deployment, network access security becomes an importantfactor for consideration.

More specifically, in virtualized data center deployments, like ACI, themovement of endpoints from one leaf port to another, or from oneendpoint group (typically tied to the dot1q VLAN the vSwitch tags tooutgoing packets) to another within the same leaf or across leafswitches of the network fabric, is very common. In such loosely-couplednetwork connectivity models, where the locality of the endpoints is notfixed, the network fabric and the endpoints become vulnerable to attacksby the rogue devices. For example, if the initial network access or thesubsequent endpoint moves are allowed without any verification, it mightlead to severe security issues. This enforces an important requirementon the underlying first hop switches that are responsible for networkconnectivity: to grant network access only to authorized endpoints anddeny connectivity to unauthorized devices.

Typically, if the switch fabric is close to saturation or if some of theexit links are almost fully loaded, accepting a new flow may create realsaturation problem leading to congestion and packet drops not only withrespect to the new flow, but also to existing flows. However, if thefabric saturation behaviors can be observed and predicted based on thecharacteristics of the first packets of a new flow (e.g., bandwidth,cycle, burstiness, etc.), the fabric can apply flow admission controlpolicies to that flow, to determine whether to grant the flow access tothe fabric.

Forecasting SDN Fabric Saturation and Machine Learning-Based FlowAdmission Control

The techniques herein introduce a proactive approach to flow admissioncontrol for an SDN fabric. In some aspects, the techniques herein use aheat map mechanism to construct a saturation model for the switchfabric. In turn, machine learning models are used to predict thecharacteristics of a new flow, based on the initial packets of the flow.These elements are then input to a flow admission control mechanism, todetermine whether to admit or deny the flow to the fabric.

Specifically, in various embodiments, a supervisory device for asoftware defined networking (SDN) fabric predicts characteristics of anew traffic flow to be admitted to the fabric, based on a set of initialpackets of the flow. The supervisory device predicts an impact ofadmitting the flow to the SDN fabric, using a heatmap-based saturationmodel for the SDN fabric. The supervisory device admits the flow to theSDN fabric, based on the predicted impact. The supervisory device usesreinforcement learning to adjust one or more call admission control(CAC) parameters of the SDN fabric, based on captured telemetry dataregarding the admitted flow.

Illustratively, the techniques described herein may be performed byhardware, software, and/or firmware, such as in accordance with thefabric saturation analysis process 248 which may include computerexecutable instructions executed by the processor 220 (or independentprocessor of interfaces 210) to perform functions relating to thetechniques described herein.

Operationally, a first component of the techniques herein provides forthe generation of a heatmap-based saturation model for the SDN fabric.Indeed, by analyzing the behavior of the switch fabric, a saturationmodel can be constructed to predict when and where the fabric willbecome saturated, if new flows are accepted onto the fabric. In variousembodiments, fabric saturation process 248 may obtain any or all of thefollowing telemetry data from the SDN fabric, to construct the heatmapmodel:

-   -   Link Utilization—how much each link in the SDN fabric is used        (e.g., in terms of number of flows, bandwidth, etc.).    -   Hardware Resource Utilization—how much CPU, memory, etc. is        consumed and/or available on each switch of the SDN fabric.    -   Queue Utilization—how much each queue is used.    -   Buffer Overflow Information—whether any buffer overflows have        occurred on a given switch of the SDN fabric.    -   Netflow or IPFIX Statistics

FIG. 4 illustrates an example heatmap for an SDN fabric, in accordancewith various embodiments. Continuing the example of FIG. 3B, assume thatany or all of the telemetry data listed above has been collected fromSDN fabric 310 over time. In various embodiments, this information canbe used to generate a machine learning-based model, such as aclassifier, that labels each switch/node in SDN fabric 310 with a‘color’ that represents its likelihood of saturation, should anotherflow be added to SDN fabric 310. For example, some switches in SDNfabric 310 (e.g., S2, M1, M4, M6, etc.) may be labeled as being onlyminimally affected by the addition of a flow. Conversely, some switchesin SDN fabric 310 (e.g., S1, M5, L3, etc.) may be labeled as beinghighly impacted by an additional flow. In between these two extremes maybe switches that may only be moderately affected by the addition of aflow (e.g., S3, S4, M2, M3, etc.).

As would be appreciated, the heatmap model may use any number ofdiscrete labels, such as “red,” “yellow,” and “green,” to represent thevarying degrees of impact that a new flow would have on that switch.Alternatively, the heatmap model may use a more continuous scale, suchas on a sliding scale from 0-1, 1-10, etc. Regardless of the type ofcoloring used, the represented impact may quantify any or all of thefollowing:

-   -   Queue length or waiting time—for example, a minimal impact label        may correspond to a new flow having little to no change on the        average queue length or queue waiting time of the node.    -   Resource usage—for example, a high impact label may correspond        to a new flow increasing the CPU usage of the switch above a        predefined threshold.    -   Link congestion—for example, a high impact label may correspond        to a new flow causing a link of the switch to exceed a        predefined level of congestion.        In addition to the above, the impact labels of the heatmap may        also take into account statistical factors, such as an average        over the prior x-number of minutes, the N-percentile        distribution over the prior x-number of minutes, water marks, or        the like.

According to various embodiments, another function of the fabricsaturation analysis process may be to predict the characteristics of anew traffic flow to be admitted to the fabric, based on a set of initialpackets of the flow. More specifically, the fabric saturation analysisprocess may train a machine learning-based model to predict how a givenflow is expected to behave in the SDN fabric, based on thecharacteristics of the first set of packets of the flow. The overallobjective of this component is to predict the characteristics of theflow, when first detected at the ingress of the network.

Closely associated with the predicted characteristics of the new floware the expected networking resources that would be required for the SDNfabric to support the flow. For example, the flow characteristicsprediction model may predict the bandwidth consumption, packet sizes,flow duration and other timing information (e.g., seasonality,inter-arrival times of packets, etc.), protocols, destinations, QoSrequirements, or the like, of the flow.

In turn, the fabric saturation process may compare the predicted flowcharacteristics of the flow to the output of its heatmap-based model ofthe SDN fabric, to determine whether the network can safely admit thenew flow considering the current states of the resources (e.g., queuelength, etc.), while meeting the required SLA for the new flow andwithout impacting the existing flows in the fabric. In addition, thefabric saturation analysis process may use the predicted flow durationof the new flow to determine whether the expectation duration is worthrejecting the new flow. For example, it may be acceptable to accept anew flow with relatively high resource requirements, if it has a veryshort duration, yet reject a flow with similar requirements, if thatflow is long-lived.

In one embodiment, a regression model could be used to compute a vectorof predicted flow characteristics, based on a series of input featuresobtained from telemetry data regarding the set of initial packets (e.g.,the first ten packets, etc.). For example, the telemetry data may becaptured by performing deep packet inspection (DPI) on the initialpackets of the flow, to capture any or all of the followingcharacteristics for input to the model:

-   -   Protocols in Use—for example, SIP, RTP, TCP, HTTP, etc.    -   Flow Seasonality    -   Source—Destination Information—e.g., the source and destination        addresses, ports, etc.    -   Payload Information    -   Packets Size Information    -   QOS Information    -   Packet inter-arrival Time Information

FIG. 5 illustrates an example architecture 500 for flow admissioncontrol in an SDN fabric, according to various embodiments. Continuingthe example of SDN fabric 310 described previously with respect to FIG.3B, assume that any number of virtual machines (VMs) are hosted by anynumber of VM hosts 502. During operation, an orchestrator 504 may beresponsible for overseeing the spawning and despawning of VMs on VMhosts 502. For example, in the case of distributed processing, each VMmay perform a particular calculation or other function, in order toproduce result data for consumption by a connecting client.

In various embodiments, architecture 500 may also include fabricsaturation analysis process 248 executed by the same device as that oforchestrator 504 or another device in communication therewith. Duringexecution, fabric saturation analysis process 248 may use the predictedflow characteristics of a new flow, and the heatmap-based saturationmodel of the fabric, both described above, to decide whether to admitthe new flow into the fabric or drop the flow, to avoid saturation andcongestion problems. In a simple embodiment, fabric saturation analysisprocess 248 may assess only a single flow characteristic, such aspredicted bandwidth consumption vs. predicted bandwidth availability inthe fabric, to determine whether to admit the flow or not. In furtherembodiments, fabric saturation analysis process 248 may assess multiplecharacteristics, to make the admission control decision. For example,fabric saturation analysis process 248 may determine whether thepredicted bandwidth of the flow exceeds one threshold, the predictedflow duration exceeds a second threshold, etc. If any or all of theseconditions are met, fabric saturation analysis process 248 may decide todrop the flow. Conversely, if fabric saturation analysis process 248determines that the flow should be admitted, it may send a calladmission control (CAC) signal to the fabric, to admit the flow.

In order to admit a flow to the fabric, fabric saturation analysisprocess 248 may also alter the ECMP ratio that a node in the fabricapplies to the admitted flow for purposes of load balancing. As would beappreciated, the equal cost load balancing offered by ECMP selects thenext switch for the flow going northward in the fabric. For example, aswitch in middle layer 314 may use its ECMP ratio to select which switchin superspine layer 312 is to receive the flow. In some embodiments, ifa flow is to be admitted to the fabric, fabric saturation analysisprocess 248 may program that the flow is to use a certain set of one ormore switches in superspine layer 312. Although not as apparent in FIG.5 for brevity purposes, a similar mechanism can be employed between leaflayer 316 and middle layer 314. In further cases, fabric saturationanalysis process 248 can also use certain paths towards superspine layer312 to observe flows that have not been seen before. Once observed,fabric saturation analysis process could use different ECMP ratios toreroute the flow to a more normal behavior.

In another embodiment, fabric saturation analysis process 248 may alsoleverage a reinforcement learning approach, to form a feedback loopafter admitting a given flow. As would be appreciated, reinforcementlearning is a machine learning approach that seeks to take actions thatmaximize a reward function. For example, assume that fabric saturationanalysis process 248 based its flow admission decision on a set ofconditions (e.g., predicted bandwidth <P, predicted duration <D, etc.).After admitting the flow, fabric saturation analysis process 248 mayleverage specialized signaling with the networking devices along thepath of the flow within the fabric, to continue to observe whether theseconditions hold true. The path taken by the flow may be dynamicallyretrieved by fabric saturation analysis process 248 by performing alookup, when a distributed routing protocol is used in the fabric.

After receiving such signaling from fabric saturation analysis process248, each receiving switch along the path of the new flow may capturetelemetry regarding the impact of the newly admitted flow. Thistelemetry data can then be sent back to fabric saturation analysisprocess 248, to evaluate the true impact on the network. If there is adiscrepancy between the predicted impact and the actual impact, fabricsaturation analysis process 248 may adjust one or more of the calladmission parameters that it uses to admit flows to the SDN fabric. Forexample, rather than compare the predicted bandwidth of a new flow to athreshold P, fabric saturation analysis process 248 may instead comparethe predicted bandwidth to an adjusted threshold P′, if the telemetrydata from the fabric indicates a discrepancy.

In further embodiments, fabric saturation analysis process 248 can alsoinfluence the spawning and placement of new VMs by orchestrator 504. Forexample, prior to orchestrator 504 spawning a new VM on one of VM hosts502, orchestrator 504 may perform a negotiation 506 with fabricsaturation analysis process 248, to assess whether the proposed VMplacement on one of VM hosts 502 would result in a new flow that couldnegatively impact the SDN network fabric.

During negotiation 506, in some embodiments, orchestrator 504 may askfabric saturation analysis process 248 for permission to place a new VMon one of VM hosts 502. Accordingly, orchestrator 504 may include thelocation of the proposed VM, as well as flow characteristics of anyflows expected for that VM, as part of the request. In some embodiments,orchestrator 504 may base the expected flow characteristics on a priorincarnation of the VM identified from a 5-tuple associated with the VM.For example, if the traffic of a previous VM has the same 5-tuple (e.g.,the source IP address/port number, destination IP address/port numberand the protocol in use) as the new VM, it may be assumed that the flowcharacteristics for the prior VM will approximate those of the new VM.In another embodiments, the expected flow characteristics for the new VMmay be based on the expected needs of the flow (e.g., the flow specs).

By way of example, if fabric saturation analysis process 248 predicts arisk of incast/congestion, before it even needs to do a CAC, it can usenegotiation 506 with orchestrator 504 to notify orchestrator 504 of thepredicted congestion. In turn, orchestrator 504 may recognize the VMsinvolved and potentially move some or all of them, to alleviate thecongestion condition. For example, fabric saturation analysis process248 may notify orchestrator 504 that incast is coming on egress port Xand that the major flows are F₁, F₂, . . . , F_(n) on ports P₁, P₂, . .. , P_(n). Orchestrator 504 can then recognize the VMs responsible forthese flows and rearrange them, as needed. Ideally, negotiation 506should lead to the final ideal port for each VM. However, if no suitablesolution is found due to high risk, fabric saturation analysis process248 may signal to orchestrator 504 to block the addition of a new VMuntil the conditions in the fabric allow for its addition.

Software defined WANs (SD-WANs) are a specialized form of SDN networkswhereby traffic between individual sites are sent over tunnels. Thetunnels are configured to use different switching fabrics, such as MPLS,Internet, 4G or 5G, etc. Often, the different switching fabrics providedifferent quality of service (QoS) at varied costs. For example, an MPLSfabric typically provides high QoS when compared to the Internet, but isalso more expensive than traditional Internet. Some applicationsrequiring high QoS (e.g., video conferencing, voice calls, etc.) aretraditionally sent over the more costly fabrics (e.g., MPLS), whileapplications not needing strong guarantees are sent over cheaperfabrics, such as the Internet.

Traditionally, network policies map individual applications to ServiceLevel Agreements (SLAs), which define the satisfactory performancemetric(s) for an application, such as loss, latency, or jitter.Similarly, a tunnel is also mapped to the type of SLA that is satisfies,based on the switching fabric that it uses. During runtime, the SD-WANedge router then maps the application traffic to an appropriate tunnel.Currently, the mapping of SLAs between applications and tunnels isperformed manually by an expert, based on their experiences and/orreports on the prior performances of the applications and tunnels.

The emergence of infrastructure as a service (IaaS) and software as aservice (SaaS) is having a dramatic impact of the overall Internet dueto the extreme virtualization of services and shift of traffic load inmany large enterprises. Consequently, a branch office or a campus cantrigger massive loads on the network.

FIGS. 6A-6B illustrate example SD-WAN deployments 600, 610,respectively. As shown, a router 110 (e.g., a device 200) located at theedge of a remote site 602 may provide connectivity between a local areanetwork (LAN) of the remote site 602 and one or more cloud-based, SaaSproviders 608 or other host for a remote application.

For example, in the case of an SD-WAN, router 110 may provideconnectivity to SaaS provider(s) 608 via tunnels across any number ofnetworks 606. This allows clients located in the LAN of remote site 602to access cloud applications (e.g., Office 365™, Dropbox™, etc.) servedby SaaS provider(s) 608.

As would be appreciated, SD-WANs allow for the use of a variety ofdifferent pathways between an edge device and an SaaS provider. Forexample, as shown in example network deployment 600 in FIG. 6A, router110 may utilize two Direct Internet Access (DIA) connections to connectwith SaaS provider(s) 608. More specifically, a first interface ofrouter 110 (e.g., a network interface 210, described previously), Int 1,may establish a first communication path (e.g., a tunnel) with SaaSprovider(s) 608 via a first Internet Service Provider (ISP) 606 a,denoted ISP 1 in FIG. 6A. Likewise, a second interface of router 110,Int 2, may establish a backhaul path with SaaS provider(s) 608 via asecond ISP 606 b, denoted ISP 2 in FIG. 6A.

FIG. 6B illustrates another example network deployment 610 in which Int1 of router 110 at the edge of remote site 602 establishes a first pathto SaaS provider(s) 608 via ISP 1 and Int 2 establishes a second path toSaaS provider(s) 308 via a second ISP 606 b. In contrast to the examplein FIG. 6A, Int 3 of router 110 may establish a third path to SaaSprovider(s) 608 via a private corporate network 606 c (e.g., an MPLSnetwork) to a private data center or regional hub 604 which, in turn,provides connectivity to SaaS provider(s) 608 via another network, suchas a third ISP 606 d.

Regardless of the specific connectivity configuration for the network, avariety of access technologies may be used (e.g., ADSL, 4G, 5G, etc.) inall cases, as well as various networking technologies (e.g., publicInternet, MPLS (with or without strict SLA), etc.) to connect the LAN ofremote site 602 to SaaS provider(s) 608. Other deployments scenarios arealso possible, such as using Colo, accessing SaaS provider(s) 608 viaZscaler or Umbrella services, and the like.

FIG. 7 illustrates an example SD-WAN node implementation 700, accordingto various embodiments. As shown, there may be a LAN core 702 at aparticular location, such as remote site 602 shown previously in FIGS.6A-6B. Connected to LAN core 702 may be one or more routers that form anSD-WAN service point 706 which provides connectivity between LAN core702 and SD-WAN fabric 704. For instance, SD-WAN service point 706 maycomprise routers 110 a-110 b.

Overseeing the operations of routers 110 a-110 b in SD-WAN service point706 and SD-WAN fabric 704 may be an SDN controller 708. In general, SDNcontroller 708 may comprise one or more devices (e.g., devices 200)configured to provide a supervisory service, typically hosted in thecloud, to SD-WAN service point 706 and SD-WAN fabric 704. For instance,SDN controller 708 may be responsible for monitoring the operationsthereof, promulgating policies (e.g., security policies, etc.),installing or adjusting IPsec routes/tunnels between LAN core 702 andremote destinations such as regional hub 604 and/or SaaS provider(s) 608in FIGS. 6A-6B and the like.

According to various embodiments, the forecasting and machinelearning-based flow admission control techniques introduced herein canalso be extended for use in an SD-WAN through the use of exogenous(extrinsic) forms of information (e.g., external tables). In general,exogeneous information is information that is not readily available tothe node, as opposed to intrinsic data or endogenous information, butcan be obtained from lookups and inferences based on extrinsic data orexogenous information. In contrast, intrinsic data refers to data aboutthe local device or node and/or other information about the other nodesthat contribute to the operation of the network, including otherrouters, the controller, hypervisors, VMs, applications, and K8ssettings in the case of containerized clients. For instance, suchintrinsic data may indicate the type of device (e.g., a router), itsinterfaces (e.g., G0/1, G0/2, etc.), and the like. In another example,the intrinsic data may include the results of analysis of the transportlayer flow control information or DPI, as detailed above. The formerindicates the pacing actions taken by the transport as a result of thedetermination by the endpoint that the network is congested. This isconsidered a failure in the learning phase of the model.

Endogenous information generally refers to information that the node cancompute locally. For instance, endogenous information may includeinformation learned by the router regarding the seasonality of flowsthat are transported through the router.

More specifically, in further embodiments, the captured telemetry dataassessed by the machine learning model may include any or all of thefollowing extrinsic data and/or exogenous information:

-   -   Extrinsic data:        -   global traffic matrix: flows that do not impact this node            but may impact the flows that traverse this node        -   global network matrix (node types and link speeds)        -   Application types and deployment    -   Exogenous information:        -   external table lookups: e.g., looking up the destination of            the SD tunnels or any other information in routing tables        -   Underlay information and hops traversed: If the tunnel is a            VXLAN then the hops are fabric nodes. In the case of SDN,            the autonomous system (AS) paths obtained from BGP (path            vector) may be considered.        -   application layout in VMs/Containers, application loads,            and/or associated transport ports

FIG. 8 illustrates an example simplified procedure for admitting a flowto an SD-WAN, in accordance with one or more embodiments describedherein. For example, a non-generic, specifically configured device in anSD-WAN (e.g., device 200, such as a router, a controller for a router,etc.) may perform procedure 800 by executing stored instructions (e.g.,process 248). The procedure 800 may start at step 805, and continues tostep 810, where, as described in greater detail above, the supervisorydevice may predict characteristics of a new traffic flow to be admittedto the SD-WAN, based on a set of initial packets of the flow. Inparticular, the supervisory device may obtain telemetry data regardingthe first n-number of packets of the flow. Such telemetry data may becaptured through DPI, Netflow, IPFIX, or other telemetry capturingmechanisms in the network. In turn, the device may use the capturedtelemetry as input to a regression or other machine learning-based modelto predict the future characteristics of the flow. For example, themodel may predict one or more of: seasonality information, protocolinformation, packet size information, inter-arrival timing information,payload information, quality of service (QoS) information, orsource-destination information regarding the flow.

At step 815, as detailed above, the device may predict an impact ofadmitting the flow to the SD-WAN, based in part on extrinsic data orexogenous information regarding the SD-WAN. Such information or data mayinclude any or all of the information or data described previously. Infurther embodiments, the device may also make the prediction based inpart on intrinsic information or data available to the device.

At step 820, the device may admit the flow to the SD-WAN, based on thepredicted impact, as described in greater detail above. Morespecifically, the device may compare the predicted flow characteristicsto one or more CAC parameters, to determine whether to admit the flow.If, for example, the path associated with the flow comprises switches orother devices that have more than sufficient resources to accommodatethe predicted requirements of the flow, the supervisory device maydetermine that admitting the flow will have little impact. Conversely,if the networking devices are already at, or near, saturation, thesupervisory device may determine that admitting the flow would have asignificant impact on the fabric. In further embodiments, thesupervisory device may also alter the ECMP ratio that a node in thefabric applies to the admitted flow, as detailed above.

At step 825, as detailed above, the supervisory device may usereinforcement learning to adjust one or more CAC parameters of theSD-WAN, based on captured telemetry data regarding the admitted flow.For example, if the admission decision is based in part on a comparisonof the predicted bandwidth of the flow to a threshold, and the telemetrydata regarding the admitted flow indicates that contention actuallyresulted, the device may lower the acceptable threshold, when makingfurther flow admission decisions. Procedure 800 then ends at step 830.

It should be noted that while certain steps within procedure 800 may beoptional as described above, the steps shown in FIG. 8 are merelyexamples for illustration, and certain other steps may be included orexcluded as desired. Further, while a particular order of the steps isshown, this ordering is merely illustrative, and any suitablearrangement of the steps may be utilized without departing from thescope of the embodiments herein. The techniques described herein,therefore, allow for flow admission control in an SDN fabric (e.g., anSD-WAN), based on the predicted characteristics of the flow and thepredicted impact of the admission on the fabric. As would beappreciated, such a proactive mechanism can greatly reduce saturationconditions in the SDN fabric.

While there have been shown and described illustrative embodiments thatprovide for flow admission control to an SDN fabric, it is to beunderstood that various other adaptations and modifications may be madewithin the spirit and scope of the embodiments herein. For example,while certain embodiments are described herein with respect to usingcertain models for purposes of predicting congestion, the models are notlimited as such and may be used for other functions, in otherembodiments. In addition, while certain protocols are shown, othersuitable protocols may be used, accordingly.

The foregoing description has been directed to specific embodiments. Itwill be apparent, however, that other variations and modifications maybe made to the described embodiments, with the attainment of some or allof their advantages. For instance, it is expressly contemplated that thecomponents and/or elements described herein can be implemented assoftware being stored on a tangible (non-transitory) computer-readablemedium (e.g., disks/CDs/RAM/EEPROM/etc.) having program instructionsexecuting on a computer, hardware, firmware, or a combination thereof.Accordingly, this description is to be taken only by way of example andnot to otherwise limit the scope of the embodiments herein. Therefore,it is the object of the appended claims to cover all such variations andmodifications as come within the true spirit and scope of theembodiments herein.

What is claimed is:
 1. A method comprising: predicting, by a device of asoftware defined wide area network (SD-WAN), characteristics of a newtraffic flow to be admitted to the SD-WAN, based on a set of initialpackets of the new traffic flow; predicting, by the device, an impact ofadmitting the new traffic flow to the SD-WAN, based in part on extrinsicdata or exogenous information regarding the SD-WAN; admitting, by thedevice, the new traffic flow to the SD-WAN, based on the impactpredicted by the device; and using, by the device, reinforcementlearning to adjust one or more call admission control (CAC) parametersof the SD-WAN, based on captured telemetry data regarding the newtraffic flow admitted to the SD-WAN, wherein the extrinsic data orexogenous information regarding the SD-WAN comprises at least one of: 1)external table lookup information indicative of routing tableinformation or one or more tunnel destinations in the SD-WAN, 2)information regarding a layout of virtual machines (VMs) or containersin which an application is executed, an application load, or transportports associated with the application, or 3) data indicative ofapplication types associated with existing traffic in the SD-WAN.
 2. Themethod as in claim 1, wherein the device comprises a router orcontroller for a router.
 3. The method as in claim 1, wherein theextrinsic data or exogenous information further comprises a globaltraffic matrix.
 4. The method as in claim 1, wherein the extrinsic dataor exogenous information further comprises a global network matrix. 5.The method as in claim 1, wherein the device predicts thecharacteristics of the new traffic flow based in part on intrinsic data,and wherein the characteristics of the new traffic flow predicted by thedevice comprise one or more of: seasonality information, protocolinformation, packet size information, inter-arrival timing information,payload information, quality of service (QoS) information, orsource-destination information regarding the new traffic flow.
 6. Atangible, non-transitory, computer-readable medium storing programinstructions that cause a device of a software defined wide area network(SD-WAN) to execute a process comprising: predicting, by the device,characteristics of a new traffic flow to be admitted to the SD-WAN,based on a set of initial packets of the new traffic flow; predicting,by the device, an impact of admitting the new traffic flow to theSD-WAN, based in part on extrinsic data or exogenous informationregarding the SD-WAN; admitting, by the device, the new traffic flow tothe SD-WAN, based on the impact predicted by the device; and using, bythe device, reinforcement learning to adjust one or more call admissioncontrol (CAC) parameters of the SD-WAN, based on captured telemetry dataregarding the new traffic flow admitted to the SD-WAN, wherein theextrinsic data or exogenous information regarding the SD-WAN comprisesat least one of: 1) external table lookup information indicative ofrouting table information or one or more tunnel destinations in theSD-WAN, 2) information regarding a layout of virtual machines (VMs) orcontainers in which an application is executed, an application load, ortransport ports associated with the application, or 3) data indicativeof application types associated with existing traffic in the SD-WAN. 7.The computer-readable medium as in claim 6, wherein the extrinsic dataor exogenous information further comprises a global traffic matrix. 8.The computer-readable medium as in claim 6, wherein extrinsic data orexogenous information further comprises a global network matrix.
 9. Anapparatus, comprising: one or more network interfaces; a processor thatis coupled to the one or more network interfaces; and a memoryconfigured to store a process that is executable by the processor, theprocess when executed configured to: predict characteristics of a newtraffic flow to be admitted to a software defined wide area network(SD-WAN), based on a set of initial packets of the new traffic flow;predict an impact of admitting the new traffic flow to the SD-WAN, basedin part on extrinsic data or exogenous information regarding the SD-WAN;admit the new traffic flow to the SD-WAN, based on the impact predictedby the apparatus; and use reinforcement learning to adjust one or morecall admission control (CAC) parameters of the SD-WAN, based on capturedtelemetry data regarding the new traffic flow admitted to the SD-WAN,wherein the extrinsic data or exogenous information regarding the SD-WANcomprises at least one of: 1) external table lookup informationindicative of routing table information or one or more tunneldestinations in the SD-WAN, 2) information regarding a layout of virtualmachines (VMs) or containers in which an application is executed, anapplication load, or transport ports associated with the application, or3) data indicative of application types associated with existing trafficin the SD-WAN.
 10. The apparatus as in claim 9, wherein the apparatuscomprises a router or controller for a router.
 11. The apparatus as inclaim 9, wherein the extrinsic data or exogenous information furthercomprises a global traffic matrix.
 12. The apparatus as in claim 9,wherein extrinsic data or exogenous information further comprises aglobal network matrix.
 13. The apparatus as in claim 9, wherein theapparatus predicts the characteristics of the new traffic flow based inpart on intrinsic data, and wherein the characteristics of the newtraffic flow predicted by the apparatus comprise one or more of:seasonality information, protocol information, packet size information,inter-arrival timing information, payload information, quality ofservice (QoS) information, or source-destination information regardingthe new traffic flow.